Integrated Computer Modeling of Engineering Design Information

One goal of computer-aided design research is the development of integrated, seamless tools that would presumably increase the efficiency of design tasks, shorten lead times, and increase product quality. This paper presents the Designer programming language, an object-oriented extension of the Scheme programming language intended to support the specification, communication, and manipulation of design information. Designer is unique because it is based on a logical theory of design information developed by the author. Also, by incorporating aspects of knowledge-based systems, Designer captures kinds of information that other systems simply cannot handle. This paper discusses Designer by example, indicating how it can be used in various design process stages, including parametric representation, top-down and bottom-up modeling, constraint specification, systems modeling, and computeraided analysis. Designer is still under development, but a full implementation is expected within one man-year. INTRODUCTION One important goal of current computer-aided design research is the development of highly integrated and seamless tools for use in design environments. Achieving this goal would presumably increase the efficiency of design processes, shorten lead times, increase product quality, and free designers from a number of relatively mundane tasks to concentrate on producing the best possible designs. The author is developing a computer language, called Designer, that is capable of representing information about designed artifacts at any phase of an engineering design process. It is intended to be a means by which information about designs can be specified, communicated, and manipulated in an integrated and seamless manner. The author is not interested at this time in producing a usable and effective user interface; that is a topic of future research. The current emphasis is on producing a system that is capable of representing the kinds of information relevant to design, and that the semantics of the language is meaningful in design. Designer has been discussed in detail elsewhere in the literature (Salustri and Venter, 1994). The focus of this paper is the application of Designer to various phases of design processes. This paper is arranged as follows. A brief description of the background theory supporting Designer's development is presented. This is followed by an introduction of the major language features and its basic modeling capabilities. The design of a four-bar linkage is used to demonstrate these capabilities. Then, a more detailed examination of Designer's range is presented, including its knowledgebased functions, as well as its use for design analysis. Finally, concluding remarks and directions for future work are presented. BACKGROUND The Designer language is an implementation of a formal theory of design information developed by the author and a collegue, called the Hybrid Model (HM) (Salustri and Venter, 1992). HM describes design information as consisting of quantities, which are combinations of values and dimensional metrics, and design entities, which are sets of quantities and other design entities. The theory is an interpretation of axiomatic set theory (Fraenkel et al., 1973), and all the logical rigor of set theory is present in HM; that is, HM is demonstrably valid with respect to set theory. The axioms of HM provide formal foundations for a variety of mechanisms that are relevant to design, including aggregation (i.e. assemblies of components), abstraction of type, specialization and generalization, and views. Otherwise intuitive notions as "An assembly cannot have itself as a component" are formalized by HM. This can permit the use of algorithmic reasoning to partially automate design tasks, alleviating some burdens normally carried by the human designer. HM is written in the language of set theory and is not prone to direct application in practical situations. However, it is used to provide the foundation of Designer; that is, Designer satisfies the axioms of HM. The focus of this paper is on the representational power of Designer, not on the (possibly automated) reasoning processes that can employ it. THE DESIGNER LANGUAGE This section introduces the major features of Designer. Designer is an object-oriented extension of the Scheme programming language, a formalized dialect of LISP (IEEE, 1991). As such, Designer may appear to be similar to a number of other object-oriented languages such as CLOS (Steele, 1990). However, Designer is unique for two reasons. Firstly, Designer is based on a formal theory of design information; indeed, Designer has the strongest logical grounding of any language for engineering applications of which the author is aware, including EXPRESS (the modeling language used in PDES/STEP). Secondly, the nature of HM requires Designer to exhibit features uncommon to other object-oriented languages. For instance, Designer does not support, nor does it require, object classes; in the terminology of object-oriented technology, it is a prototype-based language. Every object in Designer may be used to represent an actual design entity, and as an exemplar with which other objects may be created through cloning. Not only is there evidence to suggest that the human mind works more "by example" than by abstraction (Jaynes, 1976, Damasio and Damasio, 1992), but also design is one area where the generally accepted semantics of object classes can impede the development of accurate, flexible, and robust models (Johnson and Zweig, 1991, Eastman and Fereshetian, 1994). Designer supports a limited form of multiple inheritance: an object may be cloned from any number of other objects, so long as there are no naming conflicts among the inherited attributes from the parent objects. Although this is a shortcoming of the current implementation of Designer, the author has not found it to be a severe hinderance; eventually, of course, this issue will have to be resolved. Without object classes, some other mechanism to capture information about object types must exist. In Designer, this is done using a type comparison algorithm that can calculate the type-similarity of any two objects. The type comparison algorithm can also check for approximate type compatibility between objects, which means that an essentially infinite variety of partial orderings (i.e. type hierarchies) can be imposed simultaneously on a collection of objects without storing extra information. This allows Designer to represent hetrarchies as well as hierarchies; hetrarchies have been identified as organizational structures more well-suited for design information representation than hierarchies. The type algorithm is manifested as functions that can be used either to assert facts about objects, or to query an object for its relation to other objects. Some examples of these predicates are given below. (is-a? anObject Gear) exact type compatibility (~is-a anObject Gear) approximate type compatibility (similar? anObject Gear) exact type similarity (~similar anObject Gear) approximate type similarity (could-be? anObject Gear) potential type compatibility Table 1: Type-checking predicates in Designer. The is-a? predicate determines whether anObject is exactly type-compatible with object Gear; this is equivalent to determining class membership in a conventional object-oriented language. The ~is-a form, which the author refers to as a quasi-predicate (all quasi-predicates in Designer begin with the `~' symbol), returns a real number between 0 and 1 that denotes the degree to which one object is type-compatible with another. A value of 0 indicates that the two objects are not compatible at all; a value of 1 indicates that they are both "instances" of the same exemplar. The similar? predicate determines if there is a subset of the attributes of both objects that are type-compatible (i.e. if there is a common sub-exemplar, or supertype, of the two objects). The ~similar form returns a measure, between 0 and 1, of the degree of similarity between objects. Finally, could-be? is a predicate that is true if (a) an instance has fewer attributes than an exemplar, and (b) the attributes of the instance are type-compatible with attributes in the exemplar; this ability to guess the type of an object is especially important in the early phases of a design process, when decisions regarding the exact form of an artifact have not yet been made. This feature is popular in knowledge-based languages like CLASSIC (Brachman et al., 1991). Designer's type mechanism is superior to other approaches for design purposes. Firstly, it maintains a separation between abstract type information and concrete information about artifacts; this helps maintain rigor while providing seamless functionality at the user's level. Secondly, the support for quasi-predicates allows kinds of information to be captured by Designer that other systems simply cannot handle. A Designer object is an accumulation of attributes. There are three kinds of attributes in Designer: properties, components, and actions. Properties model intrinsic characteristics of entities, such as length, color, and material type. Actions -similar to methods in conventional object-oriented languages -model procedurally the behavior of objects in response to external stimuli. A component is an object that is a part of another object, capturing directly the notion of assemblies. Furthermore, a property can be explicit, storing its value directly, or derived, storing its value procedurally. For example, one could model the dimensions of an object as explicit properties, and its volume as a derived property; the procedural definition of the derived property would use the other dimensions to calculate the volume of the entity on request. Designer also supports a generic function facility that is syntactically similar to that provided by CLOS. A generic function is a function that performs different actions depending on its arguments. In CLOS, a class-based object system, the action taken by a generic function is based on the class of the object that "receives" the message. On the other hand, Designer treats all the arguments in a generic function call with equal importance. Furthermore, all of Designer's type-checking predicates can be used to distinguish argument types in generic function definitions; this gives the user a richer framework within which to specify procedural information. Finally, Designer also serves an important role within the author's research program, which includes an interest in investigating different modeling techniques for design information, with the goal of discovering the techniques best suited to the design endeavor. To provide the required flexibility for such modeling experiments, Designer remains necessarily general in nature, and not tied to some particular phase of designing (e.g. conceptual design, solid modeling, analysis, etc.) or problem domain (e.g. mechanism design). Though advantageous from a research-oriented perspective, this approach also has the practical benefit of making Designer applicable in many design phases, some of which will be discussed in the following sections of this paper. Its universality means that Designer represents a mechanism for integrating a wide variety of information commonly occuring in design processes. This brief overview has presented some of the distinguishing features of the Designer language. The rest of this paper is devoted to describing how Designer can be used in a variety of engineering tasks. BASIC CAPABILITIES In this section, some of the basic capabilities of Designer will be demonstrated. This will be done using the design of a four-bar linkage. Initially, little is known about the form and characteristics of the final design, save for (ideally) some functional requirements regarding how the linkage ought to interact with its operating environment, and possibly some constraints regarding materials selection, safety factors, etc. So, what is needed is a skeletal, schematic model of the linkage, into which other information can be added as it becomes available. Figure 1 shows a graphical schematic of the expected layout of the linkage. We do know that a four-bar linkage is composed, by definition, of four structural members pinned together into a loop. A Designer object for the linkage can be defined as follows.